Near field communication (NFC) is a communication technology that operates in short distances (for example in distances below tens of centimeters). Information may be transferred for example over RFID (radio-frequency identification) protocols. Usually, one of the parties in near field communications is a passive device, such as a card or a tag, and the other one is an active device, such as an RFID reader or a mobile phone with an integrated RFID circuitry. Also NFC communication between two active devices is possible.
A mobile phone with NFC capabilities and an incorporated secure module capable of holding sensitive information such as credit card data may act both as a passive RFID device and as an active RFID reader. For such mobile phone there are various use cases. First, users may wish to read and write information from passive RFID tags (browser shortcuts, business cards, etc.), that is, to interact with external passive devices. Secondly, the secure smartcard module hosted in the mobile phone may function as a passive RFID device itself for example for ticketing and payment applications. Thirdly, the mobile phone may act as an active device interacting with another active RFID device such as another mobile phone in peer-to-peer type of communications. That is, in the second and the third case the mobile phone interacts with external active device.
The dual nature of the usage of the NFC technology in mobile phones, when interacting with external active devices, causes a problem that one must know, which functionality to expose to external parties, which are willing to communicate with the mobile phone.
One approach to solving this situation is to always start near field communications using the MCU (Microcontroller Unit) software of the mobile phone (that is, the part of the mobile phone that may act as an active communication party) and, when it is found out that the other party actually wishes to communicate with the secure module (that is, the part of the mobile phone that may act as a passive communication party), the communication is handed over to the secure module. This approach causes two major problems. Firstly, when initiating communications, an external RFID reader wishing to communicate with a secure module first sees a certain device that does not look like a standard secure module it expects to see. Some readers might get confused with this and, for example, display an error message in a user interface, although the correct target (secure module) does appear in the field right after the mobile phone switches it on (after noticing that the communication is actually directed to the secure module). Secondly, the handover of communications to the secure module forces the handshake phase of the protocol to be redone, which may take a substantial amount of time—substantial enough to make it impossible to pass certain strict compliancy tests related to some payment applications for example.
Another approach is to always start near field communications with the secure module. However, in this case, the MCU software does not have control over the handshake process and thereby cannot make the mobile phone to initially appear as nothing else than a passive card. Thus external devices that might want to communicate with the MCU software may interpret the situation such that communication with the MCU software is not possible.
Previously, the former approach has been taken. The drawbacks have been there however. Thus, near field communication establishment may still require further considerations.